Opportunistic Locking
Microsoft Windows NT® and related operating systems support a feature called opportunistic locking. A request for an opportunistic lock (oplock) of a file object indicates that content of the file represented by the file object must be coherent while the oplock is held. Requests to open the file that can potentially access stale data should attempt to break the opportunistic lock thus forcing the oplock owner to commit content changes to the file if there are any. The opportunistic lock is associated with the file object owned by the requester. When the requester is done accessing the file, the cached modifications, if any, are made to the file, and the oplock is released. However, if an attempt is made to access an opportunistically locked file through a second file object (e.g., by another process), the oplock is typically broken, the cached modifications are made to the file, and the modified file is made available via the second file object. Thus, the lock is opportunistic, in that it is provided while feasible, but a second request to access the file can be accommodated before the first requester has let the oplock release naturally. The opportunistic locking functionality is implemented by a layer of the file system, and maintains the coherency of the file content. It is to be noted that opportunistic locking is distinct from standard deny-mode locking, in which only a single process is allowed write access to a given file at a time, and write requests by additional processes are simply denied while the deny-mode lock is in place.
Kernel Mode File System Filter Drivers
A kernel mode file system filter driver intercepts access requests directed to a file system, before the requests reach their intended targets. By intercepting requests to access files, the file system filter driver can extend or replace functionality provided by the original target of the request. A file system filter driver can be used to perform operations such as scanning files for malicious code (e.g., viruses, worms, etc.), backing up files, encrypting files, etc.
Files that are opportunistically locked cannot be reliably read from or written to from a file system filter driver in real-time, due to the possibility of breaking the coherency of the file content and deadlocking the operating system. Therefore, file system filter drivers conventionally skip accessing opportunistically locked files, and the skipped operations are performed asynchronously at a later time after the oplock has been released. However, if the access of an opportunistically locked file is skipped until later as opposed to being performed in real-time, there is a possibility of the file being modified before the core functionality of the file system filter driver is applied to the content of the file. This can result in problems such as a security vulnerability where the file system filter driver is being used to detect malicious code, or an un-backed up file where the file system filter driver is being used in a backup context.
Another conventional method of accessing an opportunistically locked file is via a separate file object which, as described above, forces the oplock to break. Forcing the oplock to break presents a problem for a file system filter based application in that the file system filter driver becomes obtrusive, and is no longer transparent. This is not acceptable in the case of a background based filter performing actions such as scanning for viruses or backing up files, because it is desirable that such background tasks be performed transparently.
It would be desirable to address these issues.